A user has a large variety of imaging format choices for printing an image. For example, Page Description Language (PDL), Raster, RAW Raster, Image data, PDL encapsulated image data, mix PDL/Raster. These different formats have different effects on the performance of the host computer and printing device. Modern Multi-Function Peripherals (MFPs) are either not designed to handle a wide mix of imaging formats, or not designed to handle them in the most performance effective manner.
FIG. 1a shows one type of printing scheme, commonly referred to as a dumb printer. The dumb printer only takes pure raster data 12 (i.e., no job control), and passes the raster data 12 straight to a marking engine 14 for printing. In this printing device, a printer driver must convert the application print data (print job) into the raster format 12 specific to the marking engine 14 for the printing device (i.e., printer swath). Thus, the printer driver performs all of the function of converting the application data to the final marking instructions such as Raster Image Processor (RIP) for the marking engine 14.
FIG. 1b shows a slightly more improved printer version sometimes referred to as a raster printer. In this printing version, the printing device has some limited print control for handling raster data with embedded job control commands 16. In this printing device, a printer driver converts the application data into a raster format specific to the marking engine 14 and embeds job control sequences with the raster data for user specified printing options (e.g., number of copies, duplex printing, etc.). The raster data with the job control sequences 16 is generally in proprietary formats and is initially processed by a job control interpreter 18. The job control interpreter 18 analyzes the print data stream 16 to extract the job control sequences from the raster data. The raster data (i.e., printer swath) is passed to the marking engine 14 for outputting. Raster data printing is then controlled by the job settings (e.g., duplex) 20 extracted from the print job 16 and by any default settings 22 set on the printing device.
FIG. 1c shows another type of modern printing device, commonly referred to as a PDL printer. The PDL printer accepts a print job in the form of a Page Description Language (PDL), such as Print Control Language (PCL), Postscript or Portable Document Format (PDF). The PDL data may also be optionally combined with job control data, such as Printer Job Language (PJL) and represents a high level description of the output, which must then be processed by the printer device into raster data (i.e., RIP).
In this case, the printer driver performs a limited amount of work to convert the application data into PDL data, and performs little to no image processing. The print controller in the printing device performs the PDL interpretation, image processing and rasterization (RIP). The PDL data may also be preceded by a job control sequence (e.g., PJL), which specifies job wide settings, such as copy count, paper sources, output bins, pagination (e.g., booklet, n-up), duplex printing and finishing (e.g., stapling, hole punch).
The Integrated Printer System (IPS) 5.02 firmware code from OAK Technologies, Wolburn, Mass. demonstrates a system for handling PJL/PDL jobs in a print controller. At the top level, a print data stream 24 is analyzed by a sniffer process 26. This process analyzes some initial number of bytes in the print data stream 24 to automatically determine the language type. If the sniffer 26 determines the input 24 is PDL (e.g., PS, PCL, PDF), the sniffer 26 passes the print job to a PDL interpreter 30. The PDL interpreter 30, as described above, performs the entire function of converting the print data 24 into the device specific raster data (i.e., printer swath) 32 which is sent to the marking engine 34. The PDL formatted print data 27 may contain job and page settings, which further control the rendering, marking, outputting and finishing of the job.
If the sniffer 26 determines the input is PJL, the print job 24 is passed to the PJL interpreter 28. The PJL interpreter 28 processes the PJL data 29 until either all the data is consumed (i.e., non-output job) or an explicit language switch command is encountered (i.e., @PJL ENTER LANGUAGE=<language>). The PJL interpreter 28 then passes the remaining print data stream that follows the explicit language switch command to the PDL interpreter 30 specified in the language switch command. The PDL interpreter 30 then performs the functions described above to eventually output the raster data 32. Additionally, the PJL interpreter 28 may output job settings 36, which further control the rendering, marking, outputting and finishing of the job. The printing device may also include default settings 38 that are combined with the job settings 36 output by the PJL interpreter 28 and PDL interpreter 30.
FIG. 1d shows a printing device that uses an IPS code with modifications that allow the supported input imaging formats to include TIFF, which is an image data format. In this device, the sniffer 40 performs the same function for PDL and PJL/PDL data as described above. If the sniffer 40 determines that the input print data 42 is TIFF, then the TIFF data is passed directly to a Tagged Image File Format (TIFF) imaging processing pipeline 44 that bypasses the PDL interpreter 46 and PJL interpreter 45. Because the image format 43 is close to the final format used by the marking engine 48 (i.e., printer swath), the TIFF image processing pipeline 44 is more efficient than the PDL pipeline that includes the PJL interpreter 45 and the PDL interpreter 46. For example, the imaging pipeline 44 can generally drive the marking engine 48 at the rated full engine speed, regardless of the complexity of the TIFF image 43.
This system still has several drawbacks. First, many of the imaging processing steps performed in the TIFF processing pipeline 44 are identical to processes in the PDL pipeline 46. Thus, the same printing processes are re-implemented in both the PDL and TIFF pipelines. Second, the TIFF pipeline 44 does not support specifying job control settings (e.g., PJL) and thus acts as a dumb printer for TIFF data.
Therefore, there is a need for an even more effective technique for supporting a wide variety of imaging formats.